§1.1 Field of the Invention
The present invention concerns methods, apparatus and data structures for providing a transport network that supports virtual private networks. The present invention also concerns configuring such a network.
§1.2 Related Art
The description of art in this section is not, and should not be interpreted to be, an admission that such art is prior art to the present invention.
§1.2.1 Known Private Networking Technologies
For many entities (such as businesses, universities, etc.), local area networks (or “LANs”) suffice for intra-entity communications. Indeed, LANs are quite popular since they are relatively inexpensive to deploy, operate, and manage, and are based on mature, well-developed technology (e.g., Ethernet). Unfortunately, however, most entities need to communicate (voice and/or data) with their own facilities, or others, beyond their immediate location. Thus, wide area networks (or “WANs”) are needed. Very often, entities want at least some privacy or security attached to their communications.
Presently, private long-haul communications can take place over networks that can be generally classified into two types—dedicated WANs that facilitate communications among multiple sites, and public transport networks that allow one or more sites of a private network to communicate. Both of these types of networks are introduced below.
§1.2.1.1 Dedicated WANs
Dedicated wide area networks (“WANs”) are typically implemented using leased lines or dedicated circuits to connect multiple sites. Customer premise equipment (“CPE”) routers or switches at theses sites connect these leased lines or dedicated circuits together to facilitate connectivity between each site of the network. Most private networks with a relatively large number of sites will not have “fully meshed” networks (i.e., direct connections between each of the sites) due to the cost of leased lines or dedicated circuits and to the complexity of configuring and managing customer premises equipment. Rather, some form of hierarchical network topology is typically employed in such instances. Dedicated WANs are relatively expensive and typically require the customer to have some networking expertise.
§1.2.1.2 Virtual Private Networks
Public transport networks, which are typically deployed by regional bell operating companies (or “RBOCs”), or some other service provider, are often used to allow remote users to connect to an enterprise network using the public-switched telephone network (or “PSTN”), an integrated services digital network (or “ISDN”), or some other type of transport network technology. (Note that the word “public” in the phrase “public transport network” connotes the fact that more than one entity may use it, even though it may be privately owned and managed, and not available to the general public.) Such remote access may be facilitated by deploying network access servers (or NASs) at one or more central cites. When users connect to (e.g., dial into) a NAS, it works with authentication, authorization and accounting (or “AAA”) servers to verify the identity of the user and to check which services that user is authorized to use.
§1.2.2 Limitations of Known Transport Network Technologies
As can be appreciated, private dedicated WANs are beyond the financial reach of most entities. Accordingly, so-called public transport networks have become quite popular. Unfortunately, however, various incompatible public transport networks have been introduced over the years in response to the then perceived needs to support various applications. Examples of such public transport network technologies include switched multimegabit data service (“SMDS”), X.25 packet switched networks, frame relay, broadband ISDN, and asynchronous transport mode (“ATM”).
The fact that public transport networks use incompatible technologies has two onerous implications for service providers. First, technologies with which customers access the transport network (referred to as “access technologies”) must be compatible with the technology used in the transport network (unless there is a handoff between networks, which is expensive). Thus, customers are locked into a technology from end-to-end. Further, as illustrated in FIG. 1, such dependencies between access technologies and transport network technologies have forced public transport network service providers to support, maintain and administer 120 separate networks 110.
Second, various applications and potential applications of communications networks, such as voice, video-on-demand, audio-on-demand, e-mail, voice-mail, video conferencing, multicasting, broadcasting, Internet access, billing, authorization, authentication, and accounting, caching, fire-walling, etc., have different network requirements, such as requirements related to maximum permissible latency, data loss, delay jitter, bandwidth, network security, etc. Consequently, customers are expected to demand various levels of service offered at various prices. Unfortunately, some of the above-referenced public transport network technologies cannot support all of the aforementioned applications. For example, they may not offer adequate bandwidth, security, and/or adequate quality of service measures to support the aforementioned applications. Even if the various public transport network technologies did provide such quality of service support, supporting various service levels and types, globally, across a number of different transport networks greatly exacerbates the problem of supporting multiple networks.
§1.2.3 Layer 3 Virtual Private Networks and Their Perceived Limitations
Layer 3 virtual private networks have been proposed. See, e.g., E. Rosen et. al., “BGP/MPLS VPNs,” RFC 2547, The Internet Society (March 1999), and B. Gleeson et al., “A Framework for IP Based Virtual Private Networks,” RFC 2764, The Internet Society (February 2000). Generally, layer 3 VPNs (“IPVPN” in particular) offer a good solution when the customer traffic is wholly IP, customer routing is reasonably simple, and the customer sites connect to the service provider with a variety of layer 2 technologies. Unfortunately, however, layer 3 VPNs have a number of perceived disadvantages. Some of these perceived disadvantages are introduced below.
First, a misbehaving customer edge device (“CE”) in a layer 3 VPN can flap its routes, leading to instability of the service provider's edge (“PE”) router or even the entire service provider network. To combat this potential problem, the service provider may aggressively damp route flaps from a CE. This is common enough with external border gateway protocol (“BGP”) peers, but in the case of VPNs, the scale of the problem is much larger. Also, if the CE-PE routing protocol is not BGP, it will not have BGP's flap damping control.
Second, with layer 3 VPNs, special care has to be taken that routes within the traditional VPN are not preferred over the Layer 3 VPN routes (often referred to as the “backdoor routing” problem). One known solution (See, e.g., RFC 2764) to this problem requires protocol changes that are somewhat ad hoc.
Third, if the service provider were participating in customer routing, it would be vital that the customer and service provider both use the same layer 3 protocol(s) and routing protocols.
Fourth, with layer 3 VPNs, each CE in a VPN may have an arbitrary number of routes that need to be carried by the service provider. This fact raises two challenges. First, both the information stored at each PE and the number of routes installed by the PE for a CE in a VPN can be (in principle) unbounded. Thus, in practice, a PE must restrict itself to installing routes associated with the VPNs that it is currently a member of. Second, a CE can send a large number of routes to its PE. Consequently, the PE should protect itself against such a condition. Thus, the service provider may enforce limits on the number of prefixes accepted from a CE. This in turn requires the PE router to offer such control.
Thus, an alternative public transport network is needed. Such a public transport network should (i) support the provision of virtual private network functions, (ii) isolate the transport network from incompetent or malicious actions by customers, (iii) minimize the number of routes that need to be stored on the service provider's routers, and/or (iv) support multicasting.